@portnov i have movement.

we probably don't want to hardcode blender-2.93.0-linux-x64 anywhere, so how does one rename
installation/blender/blender-2.93.0-linux-x64 to installation/blender/blender

something like ?

mv "installation/blender/" + ${BLENDER_DIR} installation/blender/blender
or
mv "installation/blender/${BLENDER_DIR}" installation/blender/blender
or
... ?

i don't know how to mix literals with strings.

@zeffii $VARIABLE (or ${VARIABLE}, which is the same) is just replaced with value of VARIABLE. You can think about it in terms of python's f-strings.
Python:

print(f"Hello {variable}")

Shell:

echo Hello $variable

The difference is, in shell you do not have any special "context markers" for f-strings (like f""), everything in shell is one big f-string :)

so,
Python

move(f"dir1/{BLENDER_DIR}/blender", f"dir2/{BLENDER_DIR}/blender")

Shell

mv dir1/$BLENDER_DIR/blender dir2/$BLENDER_DIR/blender

@portnov @vicdoval why is the newly downloaded blender/python dependancies gone when this job is triggered again?

that caching is a little beyond my ability to figure out,.. unless ofcourse i start throwing all kinds of mad stuff at the actions until something clicks. but maybe someone knows.

https://docs.github.com/en/actions/guides/caching-dependencies-to-speed-up-workflows

i'll keep poking at it :)

we make some kind of a key file using md5sum blender

Maybe you should change cache key? For example, "empty" -> "b29"

Hi! Portnov shared a link to this PR, so I took a peek.

The main problem here is that the cache key doesn't depend on anything, it's a fixed value. So you're using the cache that you created some time ago, and GitHub doesn't update it because the key at the end of the run is the same as at the start of the run.

You can fix this temporarily by changing the key as @portnov suggested, but you'll have to do it every time you change anything about Blender installation (e.g. Blender version or release).

A better approach would be to include Blender version in the key, something like this:

jobs:
  build:
    env:
      blender_version: "2.93"
    steps:
      - uses: actions/cache@v2
        with:
          path: ./installation
          key: blender-${{ env.blender_version }}

Now every time you change blender_version, the key will change, and the job will start without a cache. At the end of the job, GitHub will pack up ./installation and use it in all future jobs until you change blender_version again.

The cache can even depend on the workflow file itself: key: blender-${{ env.blender_version }}-${{ hashFiles('.github/workflows/test-sverchok.yml') }}. That way, when you change your Blender installation script, the cache key changes too, and GitHub is forced to create a new cache file.

Hope this helps.

Ah, and you don't need to manually add a "post cache" step, GitHub updates the cache automatically at the end of each run (if the key changed).

@Minoru that is very helpful! the syntax is new to me, but i'll have time tomorrow to complete this. if someone else doesn't do it already.

You're welcome! ae3a434 and cae2c43 don't work because the blender_version is supposed to be under env — it's an environment variable ;)

i still have no idea what i'm doing. but this is progress.

thank you for your time @Minoru ! works as hoped !

i'll keep poking around in this, and document it.